[Interactive Drive] Add physics via Physx- #423 - #430
Conversation
Signed-off-by: Ariel Glasroth <aglasroth@nvidia.com>
…ame mode is opt-in
Greptile SummaryThe PR adds a PhysX-backed physics system and scene graph to interactive drive, introduces game-mode collisions and debugging views, removes the Vulkan renderer backend, and updates compilation and benchmark infrastructure.
Confidence Score: 3/5The PR does not yet appear safe to merge because two PhysX build-lock races can still block initialization or allow concurrent mutation of the shared native-build cache. The heartbeat refresh and stale-lock reclamation remain non-atomic, so a waiter can evict a live owner and start a second build in the same CMake and module directories. Separately, a heartbeat followed by holder exit can postpone stale eligibility beyond an already-running waiter’s fixed deadline, causing first-use PhysX initialization to time out with no build left active. Files Needing Attention: integrations/omnidreams/ludus-renderer/ludus_renderer/_physx_native.py Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
CLI[Interactive-drive CLI] --> Runtime[Runtime loop]
Runtime --> Scene[Dynamic scene graph]
Scene --> Physics[PhysX simulation]
Physics --> Native[Cached native PhysX module]
Physics --> Raster[CUDA rasterizer]
Raster --> Views[Camera / BEV / debug views]
Physics --> Effects[Game-mode collisions and visual flare]
Reviews (11): Last reviewed commit: "push test fix" | Re-trigger Greptile |
|
/ok to test e425c34 |
|
/ok to test c97940a |
|
/ok to test 5210855 |
| if stale: | ||
| lock_path.unlink(missing_ok=True) | ||
| continue |
There was a problem hiding this comment.
Heartbeat stale-lock eviction race
If an active build's heartbeat touches build.lock after a waiter reads its old mtime, the waiter still unlinks the lock using that stale result. Another process can then acquire the lock and concurrently modify the shared PhysX source, CMake build, and module-output directories, causing corrupted build state or native-module build and loading failures.
Knowledge Base Used: Integrations
| # Start the wait timeout only after observing the competing lock. | ||
| # A lock created between entering this function and the first open | ||
| # attempt must get a full stale interval before we time out. | ||
| deadline = time.monotonic() + _BUILD_LOCK_TIMEOUT_SECONDS |
There was a problem hiding this comment.
Heartbeat extends lock beyond deadline
If a lock holder emits a heartbeat after another process starts waiting and then exits, the refreshed mtime postpones stale eligibility without extending the waiter's fixed deadline. The waiter therefore raises TimeoutError after 1,800 seconds even though no build remains active and the lock becomes reclaimable shortly afterward.
|
/ok to test 4dbe024 |
|
/ok to test 493592d |
|
/ok to test |
@ArielG-NV, there was an error processing your request: See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/1/ |
|
/ok to test cb82d2c |
Fixes: #313
Changes:
greencar to identify the ego on the BEV.--game-modeflag for the interactive-drive demos3, a physx-debug view. This view enabled viewing the colliders we setup on the backend of physx: vehicles, pedestrians, road-boundaries as walls, etc....